• Honor user-supplied --browser-version in Electron driver resolution
• Use concrete browser version directly instead of always fetching /releases/latest
• Gate metadata cache writes on non-empty major_browser_version to prevent empty-keyed entries
• Add regression test asserting resolved driver path contains requested version

Respect concrete browser version in Electron driver resolution

• Modified request_driver_version() to check if browser_version is concrete (non-empty, not
 stable/unstable)
• When concrete version supplied, use it directly as driver version instead of fetching
 /releases/latest
• Added guard condition for metadata cache write to only persist when both major_browser_version
 and driver_version are non-empty
• Preserved existing /releases/latest fallback for stable/unstable/empty browser versions

rust/src/electron.rs

Add regression test for browser version handling

• Added import of get_driver_path helper function from common module
• Added new regression test electron_browser_version_test that pins --browser-version 36.2.1
• Test uses --output json flag and asserts resolved driver path contains requested version
• Strengthens regression protection by verifying actual driver version, not just successful exit

rust/tests/electron_tests.rs

Description

ElectronManager::request_driver_version() now treats any non-empty --browser-version that is not
stable/unstable as an exact Electron release tag, which incorrectly includes major-only inputs
like 36 that are documented as valid. This can break existing CLI usage by producing invalid
Electron download URLs (e.g., .../download/v36/...) and causing downloads to fail.

Code

rust/src/electron.rs[R128-134]

+                let browser_version = self.get_browser_version().to_string();
+                let driver_version = if !browser_version.is_empty()
+                    && !self.is_browser_version_stable()
+                    && !self.is_browser_version_unstable()
+                {
+                    browser_version
+                } else {

Evidence

The updated Electron resolution logic short-circuits by using the raw --browser-version value as
the resolved driver_version whenever it is non-empty and not exactly stable/unstable, without
validating that it represents a full/specific version. Elsewhere in the codebase, a “specific”
version is defined as one containing a dot (.), and the CLI help documents --browser-version as
accepting a major version (in addition to channels), indicating that the Electron shortcut should be
gated to specific versions only; otherwise, major-only inputs like 36 will be treated as tag v36
and lead to invalid download URLs.

AGENTS.md: Maintain API/ABI compatibility for existing public interfaces
rust/src/electron.rs[122-142]
rust/src/lib.rs[813-819]
rust/src/main.rs[65-68]
rust/src/electron.rs[103-134]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`ElectronManager::request_driver_version()` currently returns `--browser-version` verbatim as the Electron `driver_version` for any non-empty input that is not the `stable`/`unstable` channel. This mistakenly treats major-only values (e.g., `36`)—which the CLI documents as valid major-version inputs—as exact Electron release tags, leading to invalid tag/URL construction (e.g., `.../download/v36/...`) and failed downloads.

## Issue Context
The codebase already distinguishes a “specific” version from a major version using the presence of a dot (`.`) (i.e., “specific” means it contains a dot). The CLI help for `--browser-version` explicitly describes it as a major version input and also supports channel names. Electron’s direct-return/short-circuit behavior should therefore only apply when the provided browser version is actually specific (e.g., `36.2.1`), while major-only values should continue to use the existing latest-redirect resolution (e.g., `/releases/latest`) or alternatively produce a deterministic validation error; stable/unstable handling should remain unchanged.

## Fix Focus Areas
- rust/src/electron.rs[103-155]
- rust/src/lib.rs[813-819]
- rust/src/main.rs[65-68]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

request_driver_version still checks metadata by major_browser_version before applying the pinned
--browser-version logic, so a cached entry for major "36" can override a user request for "36.2.1"
and return a different patch driver version.
This can silently violate the user’s explicit version pin.

Code

rust/src/electron.rs[R119-134]

                Ok(driver_version)
            }
            _ => {
-                self.assert_online_or_err(OFFLINE_REQUEST_ERR_MSG)?;
-
-                let latest_url = format!(
-                    "{}{}",
-                    self.get_driver_mirror_url_or_default(DRIVER_URL),
-                    LATEST_RELEASE
-                );
-                let driver_version =
-                    read_redirect_from_link(self.get_http_client(), latest_url, self.get_logger())?;
+                // Electron releases are tagged by Electron version, and the
+                // chromedriver asset shipped in each release matches that tag.
+                // When the user pins a concrete browser version (e.g.
+                // `--browser-version 36.2.1`), that version is the driver
+                // version we want; resolving via `/releases/latest` would
+                // discard the user's request and return the latest tag instead.
+                let browser_version = self.get_browser_version().to_string();
+                let driver_version = if !browser_version.is_empty()
+                    && !self.is_browser_version_stable()
+                    && !self.is_browser_version_unstable()
+                {
+                    browser_version
+                } else {

Evidence

ElectronManager returns the metadata value when present, and the metadata lookup is keyed only by
major_browser_version. Since major_browser_version for a concrete version is just the major
component, different patch pins share the same cache key and can override each other before the new
pinned-version branch runs.

rust/src/electron.rs[103-134]
rust/src/metadata.rs[123-139]
rust/src/lib.rs[1365-1374]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
Even after this PR, `ElectronManager::request_driver_version()` may return a cached driver version based on `major_browser_version` before it considers the user’s pinned full `--browser-version`. Because the metadata key is only the major component, different patch pins under the same major can conflict.

### Issue Context
- Metadata lookup for driver version keys on `major_browser_version`.
- `get_major_browser_version()` returns only the major component for non-channel inputs.
- The new pinned-version behavior lives only in the metadata-miss branch.

### Fix Focus Areas
- rust/src/electron.rs[103-155]
- rust/src/metadata.rs[123-139]
- rust/src/lib.rs[1365-1374]

### What to change
One of the following (prefer the one consistent with project behavior):
- If `--browser-version` is a specific pinned version, bypass metadata lookup entirely and return the requested (normalized) version.
- Or, key metadata lookups/writes for Electron on the full pinned version (not just the major) when `is_browser_version_specific()` is true, so separate patch pins don’t collide.

Also consider adding a regression test that runs two different `--browser-version 36.x.y` values back-to-back and asserts the second run resolves to the second requested patch.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The pinned --browser-version is used verbatim as driver_version, but get_driver_url always prefixes
the driver version with "v", so inputs like "v36.2.1" will produce "vv36.2.1" and break downloads.
This is a regression from the redirect-based path that normalizes versions via parse_version().

Code

rust/src/electron.rs[R128-142]

+                let browser_version = self.get_browser_version().to_string();
+                let driver_version = if !browser_version.is_empty()
+                    && !self.is_browser_version_stable()
+                    && !self.is_browser_version_unstable()
+                {
+                    browser_version
+                } else {
+                    self.assert_online_or_err(OFFLINE_REQUEST_ERR_MSG)?;
+                    let latest_url = format!(
+                        "{}{}",
+                        self.get_driver_mirror_url_or_default(DRIVER_URL),
+                        LATEST_RELEASE
+                    );
+                    read_redirect_from_link(self.get_http_client(), latest_url, self.get_logger())?
+                };

Evidence

ElectronManager’s URL builder hardcodes a v prefix, and the previous redirect-reading code path
normalizes via parse_version(). The new code returns the raw browser_version without normalization,
so a leading v will be doubled.

rust/src/electron.rs[122-142]
rust/src/electron.rs[163-175]
rust/src/downloads.rs[89-99]
rust/src/files.rs[530-548]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
When `--browser-version` is treated as the driver version, it is not normalized. A common user input for GitHub tags is a leading `v` (e.g., `v36.2.1`), but `get_driver_url()` already adds its own `v` prefix, yielding `vv...` and a 404.

### Issue Context
The existing online-redirect resolution path calls `read_redirect_from_link()`, which normalizes the redirect URL via `parse_version()` (stripping non-numeric prefixes such as `v`). The new bypass path skips this normalization.

### Fix Focus Areas
- rust/src/electron.rs[103-176]
- rust/src/downloads.rs[89-99]
- rust/src/files.rs[530-548]

### What to change
- Before returning `browser_version` as `driver_version`, normalize it:
 - trim whitespace
 - if it starts with `v`/`V`, strip that leading character
 - (optional) validate it’s a specific version format used by Electron assets
- Ensure the normalized value is what gets used for URL construction and cache paths.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

electron_browser_version_test asserts !driver_path.contains("vv"), but driver_path is an
absolute filesystem path so unrelated directories/usernames containing vv can fail the test. This
check also doesn’t reliably validate the intended invariant (that the resolved *version directory*
isn’t v{version}), because the cache path uses driver_version as a path component rather than
encoding the download URL.

Code

rust/tests/electron_tests.rs[R72-76]

+    assert!(
+        !driver_path.contains("vv"),
+        "resolved driver path must not contain doubled `v` prefix, got: {}",
+        driver_path
+    );

Evidence

The failing assertion operates on the entire absolute driver_path string, which can include
arbitrary user/home/cache directory names and therefore can contain vv for reasons unrelated to
Electron version resolution. Additionally, the JSON output only includes a filesystem path (not the
resolved URL), and the driver cache path structure uses the driver_version as a directory
component, so a component-based check is the correct signal.

rust/tests/electron_tests.rs[64-76]
rust/tests/common.rs[74-79]
rust/src/logger.rs[59-71]
rust/src/files.rs[521-533]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`electron_browser_version_test` uses `!driver_path.contains("vv")` to guard against a doubled `v` prefix, but that is both over-broad (flaky false failures) and not aligned with how Selenium Manager structures driver cache paths.

### Issue Context
- `get_driver_path()` parses JSON and returns `result.driver_path` as a full filesystem path.
- The cache layout uses `driver_version` as its own directory segment, so the meaningful assertion is about whether a path component is exactly `{version}` vs `v{version}`.

### Fix Focus Areas
- rust/tests/electron_tests.rs[65-76]

### Suggested change
Replace the `contains("vv")` assertion with a component-level check, e.g.:
- Parse `driver_path` with `std::path::Path`.
- Assert no component equals `format!("v{expected}")`.
- Optionally assert some component equals `expected` (stronger than substring matching).

This directly tests the normalization behavior without being sensitive to unrelated `vv` substrings elsewhere in the absolute path.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0)